개별 데이터 암호화 (Individual Data Encryption)
1. 개요
개별 데이터 암호화란 데이터베이스의 전체 저장소나 디스크 단위가 아닌, 특정 필드(Field), 컬럼(Column), 또는 개별 레코드(Record) 단위로 데이터를 암호화하여 보호하는 보안 기술이다.
이는 저장 장치 전체를 암호화하는 TDE(Transparent Data Encryption, 투명한 데이터 암호화)와 달리, 애플리케이션 계층이나 데이터베이스 엔진 내에서 특정 민감 정보만을 선택적으로 암호화한다. 따라서 관리자 권한을 가진 사용자라 하더라도 적절한 복호화 키가 없다면 실제 데이터 내용을 확인할 수 없으므로, 내부자에 의한 데이터 유출 사고를 방지하는 데 효과적이다.
2. 작동 원리 및 메커니즘
개별 데이터 암호화는 데이터가 저장소에 기록되기 전, 지정된 암호화 알고리즘과 키를 통해 평문을 암호문으로 변환하는 프로세스를 거친다.
2.1 암호화 프로세스
- 대상 식별: 암호화가 필요한 민감 데이터 필드(예: 주민등록번호, 비밀번호)를 정의한다.
- 키 호출: 키 관리 시스템(KMS)으로부터 해당 데이터에 매핑된 암호화 키를 요청한다.
- 암호화 수행: 선택된 알고리즘(AES 등)을 사용하여 데이터를 암호화한다.
- 저장: 암호화된 결과값(Ciphertext)을 데이터베이스에 저장한다.
2.2 키 관리 체계 (KMIP)
개별 데이터 암호화에서는 수많은 키가 생성되므로 효율적인 관리가 필수적이다. 이를 위해 KMIP(Key Management Interoperability Protocol) 표준이 주로 사용된다. KMIP는 서로 다른 제조사의 키 관리 서버와 클라이언트 간의 상호 운용성을 보장하는 프로토콜로, 키의 생성, 저장, 배포, 폐기 과정을 표준화하여 관리한다.
2.3 전체 암호화 vs 개별 암호화 비교
| 구분 |
전체 암호화 (TDE/Disk Encryption) |
개별 데이터 암호화 (Field-level) |
| 암호화 단위 |
디스크 볼륨, 데이터 파일 전체 |
특정 컬럼, 필드, 개별 레코드 |
| 보호 대상 |
물리적 저장 매체 도난/분실 대비 |
데이터베이스 접근 권한 오남용 대비 |
| 성능 영향 |
상대적으로 낮음 (I/O 단계에서 처리) |
상대적으로 높음 (데이터별 연산 필요) |
| 관리 복잡도 |
낮음 (단일 키 또는 소수 키 관리) |
높음 (필드/사용자별 다양한 키 관리 가능) |
| 복호화 시점 |
OS/DB 엔진이 읽을 때 자동 복호화 |
애플리케이션 또는 특정 권한 요청 시 복호화 |
3. 주요 암호화 방식
3.1 대칭키 및 비대칭키 적용
- 대칭키 암호화: 암호화와 복호화에 동일한 키를 사용한다. 속도가 빨라 대량의 데이터 필드 암호화에 주로 사용된다. (예: AES-256, ChaCha20)
- 비대칭키 암호화: 공개키로 암호화하고 개인키로 복호화한다. 속도는 느리지만 키 전달이 안전하여, 매우 민감한 데이터의 초기 전송이나 디지털 서명에 사용된다. (예: RSA, ECC, Ed25519)
- 주의: 비대칭키 암호화는 연산 비용이 매우 높고 암호문 크기가 커지므로, DB 컬럼 전체를 직접 암호화하여 저장하는 용도로는 거의 사용되지 않는다. 주로 데이터 저장보다는 키 교환이나 전자서명 등 보조적인 수단으로 활용된다.
- 결정적 암호화 (Deterministic Encryption): 동일한 평문은 항상 동일한 암호문으로 변환된다. 데이터의 일관성이 유지되어 암호화된 상태에서도
WHERE 절을 통한 일치 검색이 가능하다.
- 확률적 암호화 (Probabilistic Encryption): 동일한 평문이라도 암호화할 때마다 매번 다른 암호문이 생성된다(솔트/IV 사용). 보안성은 매우 높으나, 암호화된 상태에서의 검색이 불가능하며 반드시 복호화 후 비교해야 한다.
[결정적 vs 확률적 암호화 비교]
| 구분 |
결정적 암호화 |
확률적 암호화 |
| 결과값 |
동일 평문 $\rightarrow$ 동일 암호문 |
동일 평문 $\rightarrow$ 매번 다른 암호문 |
| 보안성 |
상대적으로 낮음 (패턴 분석 가능) |
매우 높음 (패턴 분석 불가능) |
| 검색 가능 여부 |
일치 검색(Exact Match) 가능 |
복호화 전까지 검색 불가능 |
| 주요 용도 |
인덱싱이 필요한 식별자 필드 |
매우 높은 보안이 필요한 개인정보 |
3.3 암호화/복호화 의사코드 (Pseudo-code)
# 특정 필드(Email)에 대한 암호화 및 복호화 예시
from cryptography.fernet import Fernet
# 1. 키 생성 및 로드 (실제 환경에서는 KMS에서 호출)
key = Fernet.generate_key()
cipher_suite = Fernet(key)
# 2. 암호화 프로세스 (평문 -> 암호문)
plain_text = "user@example.com".encode('utf-8')
cipher_text = cipher_suite.encrypt(plain_text)
print(f"Encrypted: {cipher_text}")
# 3. 복호화 프로세스 (암호문 -> 평문)
decrypted_text = cipher_suite.decrypt(cipher_text).decode('utf-8')
print(f"Decrypted: {decrypted_text}")
4. 활용 사례 및 적용 분야
4.1 법적 규제 준수 (Compliance)
개인정보 보호법 및 GDPR(유럽 일반 데이터 보호 규칙)에 따라 주민등록번호, 계좌번호, 카드번호와 같은 고유 식별 정보는 반드시 암호화하여 저장해야 한다. 개별 데이터 암호화를 통해 데이터베이스 관리자(DBA)조차 실제 개인정보를 볼 수 없도록 제어함으로써 법적 리스크를 최소화한다.
4.2 클라우드 멀티 테넌시(Multi-tenancy) 환경
하나의 인프라를 여러 고객사(Tenant)가 공유하는 SaaS 환경에서, 각 고객사별로 서로 다른 암호화 키를 할당하는 'Tenant-specific Key' 전략을 사용한다. 이를 통해 특정 고객사의 데이터가 유출되더라도 다른 고객사의 데이터는 안전하게 격리되는 효과를 얻을 수 있다.
4.3 데이터 흐름도 (Data Flow)
graph LR
A[사용자 요청] --> B[애플리케이션 서버]
B --> C{KMS}
C -- 키 요청/수신 --> B
B -- 데이터 암호화 수행 --> D[DB 저장/암호문]
D -- DB 응답/암호문 --> B
B -- 데이터 복호화 --> E[사용자 결과 전달]
5. 장점과 한계점
5.1 장점
- 세밀한 접근 제어: 사용자 역할(Role)에 따라 특정 필드의 복호화 권한을 차등 부여할 수 있다.
- 강력한 보안성: 스토리지 전체가 탈취되거나 DB 덤프 파일이 유출되어도 키가 없다면 데이터 내용을 알 수 없다.
- 최소 권한 원칙 구현: 애플리케이션 계층에서 복호화를 수행함으로써 DB 서버의 권한 노출을 최소화한다.
5.2 한계점
- 인덱싱 성능 저하: 암호화된 데이터는 원래의 정렬 순서를 잃어버리므로, 범위 검색(
BETWEEN, >, <)이 불가능하며 인덱스 효율이 급격히 떨어진다.
- CPU 오버헤드: 매 레코드마다 암/복호화 연산이 발생하므로 시스템 전체의 CPU 사용량이 증가한다.
- 데이터 길이 증가: 암호화 후의 데이터(Ciphertext)는 평문보다 길이가 길어지므로 DB 스키마 변경(컬럼 크기 확장)이 필요하다.
6. 구현 시 고려사항
6.1 암호화 알고리즘 추천 표준
데이터의 특성과 요구 보안 수준에 따라 아래 표준 알고리즘 사용을 권장한다.
| 데이터 유형 |
추천 알고리즘 |
특성 |
| 일반 민감 정보 |
AES-256 (GCM 모드), ChaCha20 |
양방향 암호화, 높은 보안성과 무결성 검증 가능 |
| 비밀번호 |
Argon2, bcrypt, scrypt |
단방향 암호화(해시), 솔팅(Salting) 필수, 복호화 불가능 |
| 키 교환/서명 |
ECDSA, Ed25519, RSA-4096 |
비대칭키 암호화, 짧은 키 길이로 높은 보안 수준 제공 |
6.2 인덱싱 성능 저하 해결을 위한 검색 기법
암호화된 필드에 대한 검색 성능을 확보하기 위해 다음과 같은 기법을 적용한다.
- 검색용 인덱스 컬럼(Blind Index) 생성: 평문을 해시 함수(HMAC 등)로 처리하여 별도의 컬럼에 저장한다. 검색 시 검색어 역시 동일하게 해싱하여 일치 여부를 확인하는 방식으로, 원본 데이터는 보호하면서 빠른 일치 검색이 가능하다.
- 부분 암호화 (Partial Encryption): 데이터의 전체가 아닌 일부(예: 카드번호 뒷 4자리 제외)만 암호화하여, 검색에 필요한 최소한의 정보는 평문으로 유지한다.
- Order-Preserving Encryption (OPE): 암호화 후에도 평문의 순서가 유지되는 특수 암호화 방식을 사용하여 범위 검색을 지원한다. (단, 보안성은 일반 암호화보다 낮음)
6.3 운영 관리 전략
- 키 로테이션 (Key Rotation): 특정 주기(예: 1년) 또는 키 유출 의심 시 키를 교체한다. 기존 데이터의 재암호화 비용을 줄이기 위해 '마스터 키'와 '데이터 암호화 키(DEK)'를 분리하는 Envelope Encryption 구조를 권장한다.
- 복호화 권한 관리: 복호화 API 호출 로그를 전수 기록하여, 누가 언제 어떤 민감 데이터에 접근했는지 감사 추적(Audit Trail)이 가능하도록 설계해야 한다.
[관련 용어]
- TDE (Transparent Data Encryption): 데이터베이스 파일 자체를 암호화하여 물리적 저장 매체 유출 시 데이터를 보호하는 기술.
- KMS (Key Management Service): 암호화 키의 생성, 저장, 배포, 로테이션을 중앙에서 관리하는 서비스.
- HMAC (Hash-based Message Authentication Code): 해시 함수와 비밀키를 결합하여 데이터의 무결성과 인증을 동시에 확인하는 코드.
- IV (Initialization Vector): 동일한 평문이 동일한 암호문으로 생성되는 것을 방지하기 위해 암호화 시 추가하는 무작위 값.
- Envelope Encryption: 데이터를 암호화하는 키(DEK)를 다시 마스터 키(KEK)로 암호화하여 관리하는 계층적 암호화 방식.
# 개별 데이터 암호화 (Individual Data Encryption)
## 1. 개요
**개별 데이터 암호화**란 데이터베이스의 전체 저장소나 디스크 단위가 아닌, 특정 필드(Field), 컬럼(Column), 또는 개별 레코드(Record) 단위로 데이터를 암호화하여 보호하는 보안 기술이다.
이는 저장 장치 전체를 암호화하는 TDE(Transparent Data Encryption, 투명한 데이터 암호화)와 달리, 애플리케이션 계층이나 데이터베이스 엔진 내에서 특정 민감 정보만을 선택적으로 암호화한다. 따라서 관리자 권한을 가진 사용자라 하더라도 적절한 복호화 키가 없다면 실제 데이터 내용을 확인할 수 없으므로, 내부자에 의한 데이터 유출 사고를 방지하는 데 효과적이다.
## 2. 작동 원리 및 메커니즘
개별 데이터 암호화는 데이터가 저장소에 기록되기 전, 지정된 암호화 알고리즘과 키를 통해 평문을 암호문으로 변환하는 프로세스를 거친다.
### 2.1 암호화 프로세스
1. **대상 식별**: 암호화가 필요한 민감 데이터 필드(예: 주민등록번호, 비밀번호)를 정의한다.
2. **키 호출**: 키 관리 시스템(KMS)으로부터 해당 데이터에 매핑된 암호화 키를 요청한다.
3. **암호화 수행**: 선택된 알고리즘(AES 등)을 사용하여 데이터를 암호화한다.
4. **저장**: 암호화된 결과값(Ciphertext)을 데이터베이스에 저장한다.
### 2.2 키 관리 체계 (KMIP)
개별 데이터 암호화에서는 수많은 키가 생성되므로 효율적인 관리가 필수적이다. 이를 위해 **KMIP(Key Management Interoperability Protocol)** 표준이 주로 사용된다. KMIP는 서로 다른 제조사의 키 관리 서버와 클라이언트 간의 상호 운용성을 보장하는 프로토콜로, 키의 생성, 저장, 배포, 폐기 과정을 표준화하여 관리한다.
### 2.3 전체 암호화 vs 개별 암호화 비교
| 구분 | 전체 암호화 (TDE/Disk Encryption) | 개별 데이터 암호화 (Field-level) |
| :--- | :--- | :--- |
| **암호화 단위** | 디스크 볼륨, 데이터 파일 전체 | 특정 컬럼, 필드, 개별 레코드 |
| **보호 대상** | 물리적 저장 매체 도난/분실 대비 | 데이터베이스 접근 권한 오남용 대비 |
| **성능 영향** | 상대적으로 낮음 (I/O 단계에서 처리) | 상대적으로 높음 (데이터별 연산 필요) |
| **관리 복잡도** | 낮음 (단일 키 또는 소수 키 관리) | 높음 (필드/사용자별 다양한 키 관리 가능) |
| **복호화 시점** | OS/DB 엔진이 읽을 때 자동 복호화 | 애플리케이션 또는 특정 권한 요청 시 복호화 |
## 3. 주요 암호화 방식
### 3.1 대칭키 및 비대칭키 적용
- **대칭키 암호화**: 암호화와 복호화에 동일한 키를 사용한다. 속도가 빨라 대량의 데이터 필드 암호화에 주로 사용된다. (예: AES-256, ChaCha20)
- **비대칭키 암호화**: 공개키로 암호화하고 개인키로 복호화한다. 속도는 느리지만 키 전달이 안전하여, 매우 민감한 데이터의 초기 전송이나 디지털 서명에 사용된다. (예: RSA, ECC, Ed25519)
- **주의**: 비대칭키 암호화는 연산 비용이 매우 높고 암호문 크기가 커지므로, DB 컬럼 전체를 직접 암호화하여 저장하는 용도로는 거의 사용되지 않는다. 주로 데이터 저장보다는 키 교환이나 전자서명 등 보조적인 수단으로 활용된다.
### 3.2 결정적 암호화 vs 확률적 암호화
- **결정적 암호화 (Deterministic Encryption)**: 동일한 평문은 항상 동일한 암호문으로 변환된다. 데이터의 일관성이 유지되어 암호화된 상태에서도 `WHERE` 절을 통한 일치 검색이 가능하다.
- **확률적 암호화 (Probabilistic Encryption)**: 동일한 평문이라도 암호화할 때마다 매번 다른 암호문이 생성된다(솔트/IV 사용). 보안성은 매우 높으나, 암호화된 상태에서의 검색이 불가능하며 반드시 복호화 후 비교해야 한다.
**[결정적 vs 확률적 암호화 비교]**
| 구분 | 결정적 암호화 | 확률적 암호화 |
| :--- | :--- | :--- |
| **결과값** | 동일 평문 $\rightarrow$ 동일 암호문 | 동일 평문 $\rightarrow$ 매번 다른 암호문 |
| **보안성** | 상대적으로 낮음 (패턴 분석 가능) | 매우 높음 (패턴 분석 불가능) |
| **검색 가능 여부** | 일치 검색(Exact Match) 가능 | 복호화 전까지 검색 불가능 |
| **주요 용도** | 인덱싱이 필요한 식별자 필드 | 매우 높은 보안이 필요한 개인정보 |
### 3.3 암호화/복호화 의사코드 (Pseudo-code)
```python
# 특정 필드(Email)에 대한 암호화 및 복호화 예시
from cryptography.fernet import Fernet
# 1. 키 생성 및 로드 (실제 환경에서는 KMS에서 호출)
key = Fernet.generate_key()
cipher_suite = Fernet(key)
# 2. 암호화 프로세스 (평문 -> 암호문)
plain_text = "user@example.com".encode('utf-8')
cipher_text = cipher_suite.encrypt(plain_text)
print(f"Encrypted: {cipher_text}")
# 3. 복호화 프로세스 (암호문 -> 평문)
decrypted_text = cipher_suite.decrypt(cipher_text).decode('utf-8')
print(f"Decrypted: {decrypted_text}")
```
## 4. 활용 사례 및 적용 분야
### 4.1 법적 규제 준수 (Compliance)
개인정보 보호법 및 GDPR(유럽 일반 데이터 보호 규칙)에 따라 주민등록번호, 계좌번호, 카드번호와 같은 고유 식별 정보는 반드시 암호화하여 저장해야 한다. 개별 데이터 암호화를 통해 데이터베이스 관리자(DBA)조차 실제 개인정보를 볼 수 없도록 제어함으로써 법적 리스크를 최소화한다.
### 4.2 클라우드 멀티 테넌시(Multi-tenancy) 환경
하나의 인프라를 여러 고객사(Tenant)가 공유하는 SaaS 환경에서, 각 고객사별로 서로 다른 암호화 키를 할당하는 **'Tenant-specific Key'** 전략을 사용한다. 이를 통해 특정 고객사의 데이터가 유출되더라도 다른 고객사의 데이터는 안전하게 격리되는 효과를 얻을 수 있다.
### 4.3 데이터 흐름도 (Data Flow)
```mermaid
graph LR
A[사용자 요청] --> B[애플리케이션 서버]
B --> C{KMS}
C -- 키 요청/수신 --> B
B -- 데이터 암호화 수행 --> D[DB 저장/암호문]
D -- DB 응답/암호문 --> B
B -- 데이터 복호화 --> E[사용자 결과 전달]
```
## 5. 장점과 한계점
### 5.1 장점
- **세밀한 접근 제어**: 사용자 역할(Role)에 따라 특정 필드의 복호화 권한을 차등 부여할 수 있다.
- **강력한 보안성**: 스토리지 전체가 탈취되거나 DB 덤프 파일이 유출되어도 키가 없다면 데이터 내용을 알 수 없다.
- **최소 권한 원칙 구현**: 애플리케이션 계층에서 복호화를 수행함으로써 DB 서버의 권한 노출을 최소화한다.
### 5.2 한계점
- **인덱싱 성능 저하**: 암호화된 데이터는 원래의 정렬 순서를 잃어버리므로, 범위 검색(`BETWEEN`, `>`, `<`)이 불가능하며 인덱스 효율이 급격히 떨어진다.
- **CPU 오버헤드**: 매 레코드마다 암/복호화 연산이 발생하므로 시스템 전체의 CPU 사용량이 증가한다.
- **데이터 길이 증가**: 암호화 후의 데이터(Ciphertext)는 평문보다 길이가 길어지므로 DB 스키마 변경(컬럼 크기 확장)이 필요하다.
## 6. 구현 시 고려사항
### 6.1 암호화 알고리즘 추천 표준
데이터의 특성과 요구 보안 수준에 따라 아래 표준 알고리즘 사용을 권장한다.
| 데이터 유형 | 추천 알고리즘 | 특성 |
| :--- | :--- | :--- |
| **일반 민감 정보** | AES-256 (GCM 모드), ChaCha20 | 양방향 암호화, 높은 보안성과 무결성 검증 가능 |
| **비밀번호** | Argon2, bcrypt, scrypt | **단방향 암호화(해시)**, 솔팅(Salting) 필수, 복호화 불가능 |
| **키 교환/서명** | ECDSA, Ed25519, RSA-4096 | 비대칭키 암호화, 짧은 키 길이로 높은 보안 수준 제공 |
### 6.2 인덱싱 성능 저하 해결을 위한 검색 기법
암호화된 필드에 대한 검색 성능을 확보하기 위해 다음과 같은 기법을 적용한다.
- **검색용 인덱스 컬럼(Blind Index) 생성**: 평문을 해시 함수(HMAC 등)로 처리하여 별도의 컬럼에 저장한다. 검색 시 검색어 역시 동일하게 해싱하여 일치 여부를 확인하는 방식으로, 원본 데이터는 보호하면서 빠른 일치 검색이 가능하다.
- **부분 암호화 (Partial Encryption)**: 데이터의 전체가 아닌 일부(예: 카드번호 뒷 4자리 제외)만 암호화하여, 검색에 필요한 최소한의 정보는 평문으로 유지한다.
- **Order-Preserving Encryption (OPE)**: 암호화 후에도 평문의 순서가 유지되는 특수 암호화 방식을 사용하여 범위 검색을 지원한다. (단, 보안성은 일반 암호화보다 낮음)
### 6.3 운영 관리 전략
- **키 로테이션 (Key Rotation)**: 특정 주기(예: 1년) 또는 키 유출 의심 시 키를 교체한다. 기존 데이터의 재암호화 비용을 줄이기 위해 '마스터 키'와 '데이터 암호화 키(DEK)'를 분리하는 **Envelope Encryption** 구조를 권장한다.
- **복호화 권한 관리**: 복호화 API 호출 로그를 전수 기록하여, 누가 언제 어떤 민감 데이터에 접근했는지 감사 추적(Audit Trail)이 가능하도록 설계해야 한다.
## [관련 용어]
- **TDE (Transparent Data Encryption)**: 데이터베이스 파일 자체를 암호화하여 물리적 저장 매체 유출 시 데이터를 보호하는 기술.
- **KMS (Key Management Service)**: 암호화 키의 생성, 저장, 배포, 로테이션을 중앙에서 관리하는 서비스.
- **HMAC (Hash-based Message Authentication Code)**: 해시 함수와 비밀키를 결합하여 데이터의 무결성과 인증을 동시에 확인하는 코드.
- **IV (Initialization Vector)**: 동일한 평문이 동일한 암호문으로 생성되는 것을 방지하기 위해 암호화 시 추가하는 무작위 값.
- **Envelope Encryption**: 데이터를 암호화하는 키(DEK)를 다시 마스터 키(KEK)로 암호화하여 관리하는 계층적 암호화 방식.